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ABSTRACT 

This  paper  identifies  eight  factors  critical  to  the 
successsful  implementation  of  executive  support  systems. 
Findings  are  based  on  interviews  done  in  30  companies  which 
have  tried  to  implement  computer-based  support  systems  for 
top  management.  The  factors  identified  cover  issues  such  as 
sponsorship,  linking  the  system  to  a  business  objective, 
technology  used,  and  the  management  of  data,  political 
resistance,  and  system  evolution.  A  case  study  of  one 
company's  attempts  tx>   implement  an  executive  support  system 
is  presented  to  illustrate  the  eight  factors. 


The  use  of  computers  by  top  management,  known  as 
executive  support  systems  (ESS) ,  is  a  steadily  growing 
phenomenon,  one  that  can  have  major  impacts  on  the  nature  of 
executive  work  and  the  way  organizations  function.  Like  any 
new  application  of  information  technology,  however,  ESS  is 
fraught  with  pitfalls.  Technological,  organizational, 
psychological  and  educational  issues  all  contribute  variables 
that  make  the  implementation  of  executive  support  systems 
difficult. 

Much  has  changed  in  the  four  years  since  Rockart  and 
Treacy  first  identified  the  executive  computing  phenomenon 
(Rockart/Treacy,  1982)  .  At  the  time  they  found  only  a  handful 
of  top  managers  making  use  of  the  technology.  But,  in  late 
1984,  a  survey  of  45  randomly-selected  Fortune  500  companies 
revealed  that  two-thirds  of  them  had  at  least  one  executive, 
and  usually  several,  with  a  computer  terminal  on  his  or  her 
desk  (De  Long/Rockart,1984) .  Slowly  but  steadily  the  concept 
of  top  management  computer  use  is  gaining  credibility. 

One  of  the  major  barriers  to  the  spread  of  ESS  has 
been  our  lack  of  understanding  of  how  to  implement  these 
systems.  Unlike  more  mature  I/S  applications,  such  as 
transaction  processing  and  decision  support  systems,  we  have 
lacked  sufficient  experience  to  develop  an  appropriate 
methodology  for  implementing  ESS.  Implementation  of  systems 
for  executives  presents  problems  not  experienced  in  systems 
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designed  for  middle  management.  The  fragmented  nature  of 
executive  work,  the  high  degree  of  environmental  uncertainty 
at  this  level  of  the  organization,  and  the  political 
ramifications  of  giving  top  management  more  and  better 
information  make  implementing  ESS  a  special  challenge. 

The  purpose  of  this  paper  is  to  propose  an  outline  of 
critical  ESS  implementation  issues,  based  on  a  preliminary 
analysis  of  field  studies  done  at  the  Sloan  School's  Center 
for  Information  Systems  Research  over  the  last  eighteen 
months.  Our  framework  is  based  on  an  in  depth  study  of  almost 
30  companies  which  have  tried  to  install  ESS.  The  research 
involved  extensive  field  interviews  with  both  ESS  developers 
and  users  in  firms  representing  a  broad  cross  section  of 
industries.  To  illustrate  many  of  the  critical  points  in  the 
paper  we  will  use  a  case  study  of  one  computer  company's 
attempt  at  implementing  an  executive  support  system. 

Defining  Executive  Support  Systems 

One  of  the  problems  with  implementing  executive 
support  systems  is  the  difficulty  in  defining  the  concept. 
There  is  still  great  confusion  about  what  really  constitutes 
such  a  system.  What  one  firm  might  consider  an  executive 
support  system,  another  will  discount  as  "just  a  personal 
computer"  or  "just  electronic  mail."  But,  unless  the 
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boundaries  and  purpose  of  an  ESS  are  carefully  conceived,  it 
is  hard  to  implement  an  effective  system. 

Levinson  (1984)  defined  ESS  as  "terminal-based 
computer  systems  designed  to  aid  senior  executives  in  the 
management  of  the  firm."  We  have  defined  it  a  little  more 
specifically  (De  Long/Rockart, 1984)  as  "the  routine  use  of  a 
computer  terminal  by  either  the  CEO  or  a  member  of  the  senior 
management  team  reporting  directly  to  him  (or  her) .  The  use 
may  be  for  any  management  function,  and  these  systems  can  be 
implemented  at  the  corporate  and/or  divisional  level." 

FACTORS  IN  ERR  IMPLEMENTATION 

There  is  a  substantial  body  of  literature  on 
information  systems  implementation  (Markus,  1979) . 
Unfortunately,  there  is  no  clear  agreement  in  this  literature 
as  to  the  factors  that  are  most  significant  in  making  the 
implementation  process  successful  or  as  to  the  best  process 
to  follow.  As  we  have  looked  at  dozens  of  attempts  at 
implementing  ESS,  there  seem  to  be  eight  critical  factors  in 
assuring  top  management  acceptance  and  use  of  a  system.  They 
are: 


1.  A  Committed  and  Informed  Executive  Sponsor. 
There  must  be  an  executive  who  has  both  a 
realistic  understanding  of  the  capabilities  (and 
limitations)  of  ESS,  and  who  really  wants  the 
system  so  badly  that  he  or  she  is  willing  to  put 
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considerable  time  and  energy  into  seeing  that  a 
system  gets  developed. 

An  Operating  Sponsor.  Because  the  executive 
sponsor  usually  lacks  sufficient  time  to  devote 
to  the  project,  it  appears  very  worthwhile  to 
have  an  "operating  sponsor"  designated  to  manage 
the  details  of  implementation  from  the  user's 
side.  This  person  is  usually  a  trusted 
subordinate  or  an  executive  assistant  who  is 
well  acquainted  with  the  sponsor's  work  style 
and  way  of  thinking. 

Clear  T.ink  to  Business  Ob jecti ve  ( s)  .  The  ESS 
must  solve  a  business  problem  or  meet  a  need 
that  is  addressed  most  effectively  with  I/S 
technology.  There  should  be  a  clear  benefit  to 
using  the  technology.  It  must  provide  something 
that  would  not  otherwise  be  available,  such  as 
graphical  displays,  data  with  textual 
annotations,  etc.  Simply  getting  access  to  the 
"same  old  data"  through  a  terminal  may  not  be  as 
good  as  the  existing  paper-based  system,  unless 
there  is  some  value  added  to  the  data. 

Appropriate  I/S  Resources.  The  quality  of 
the  ESS  project  manager  on  the  I/S  side  is  most 
critical.  This  person  should  have  not  only 
technical  knowledge,  but  also  business  knowledge 
and  the  ability  to  communicate  effectively  with 
senior  management. 

Appropriate  Technology.  The  choice  of 
hardware  and  software  used  has  a  major  bearing 
on  the  acceptance  or  rejection  of  a  system.  One 
of  the  early  barriers  to  executive  support  has 
been  the  lack  of  hardware  and  software  that 
could  meet  the  demands  of  highly-variable 
executive  work  styles  and  environments.  Things 
are  getting  better,  however,  as  more  and  more 
products  are  being  designed  specifically  for  the 
ESS  market. 

Management  of  Data  Problems.  The  physical 
and  technical  ability  to  provide  access  to 
reliable  data  can  be  a  major  issue  in  ESS 
development.  Aggregating,  accessing  and  managing 
production  databases  in  a  corporation  with 
multiple  divisions  can  be  the  biggest  physical 
roadblock  to  ESS  implementation. 
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7.  Management  of  Organizational  Resistance. 
Political  resistance  to  ESS  is  one  of  the  most 
common  causes  of  implementation  failure.  An  ESS 
alters  information  flows  and  this  always  has  the 
potential  to  significantly  shift  power 
relationships  in  a  company.  Anticipating  and 
managing  the  political  ramifications  of  an  ESS 
will  remain  a  potential  problem  throughout  the 
life  of  the  system. 

8.  Management  of  Sprpad  and  System  Evolution. 
An  installation  that  is  successful  and  used 
regularly  by  the  executive  sponsor  usually  will 
produce  pressures  for  rapid  evolution  of  the 
system  as  the  user  quickly  recognizes  other 
potential  applications.  A  useful  ESS  will  also 
inevitably  produce  demands  by  peers  or 
subordinates  for  access  to  a  similar  system. 
Managing  the  process  of  "spread"  means 
identifying  the  specific  job  function,  technical 
orientation,  work  style,  and  specific 
information  support  needs  of  each  potential 
user,  and  taking  that  into  account  when 
expanding  the  system. 

It  is  worth  pointing  out  that  these  eight  factors  in 
ESS  implementation  are  essentially  prescriptive,  based  on  a 
sample  of  about  30  cases.  Most,  or  all,  of  the  eight  elements 
appear  to  be  present  during  the  implementation  of  the  systems 
we  have  studied,  which  have  been  deemed  most  successful  by 
both  the  executive  users  and  the  developers.  While  we  cannot 
prove  that  the  factors  listed  above  will  lead  to  system 
acceptance,  we  do  have  substantial  evidence  that  failure  to 
consider  these  issues  certainly  increases  the  chances  of 
system  failure. 

To  illustrate  these  eight  factors  more  effectively,  we 
present  a  case  of  one  computer  company's  attempt  at 
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implementing  an  executive  support  system.  The  case  is  helpful 
because  it  clearly  illustrates  each  of  the  factors  we  have 
discussed  above.  The  case  has  been  significantly  disguised. 

STQWE  COMPUTER  CORPORATION 

In  the  early  1980s  Stowe  Computer  Corporation  (SCC) 
experienced  serious  financial  difficulties.  The  firm  lost  $75 
million  in  1981  and  was  on  the  verge  of  bankruptcy.  Survival 
was  the  fundamental  issue  for  the  company  when  Roger  Weathers 
was  brought  in  as  the  new  president  and  CEO  that  year. 
Weathers'  word  quickly  became  law  and  decision  making  was 
very  centralized  in  the  early  days  of  his  tenure  at  SCC. 
During  this  period,  about  8,000  people,  or  one-third  of  SCC's 
workforce  were  laid  off,  and  the  president  worked  on  an 
entirely  new  product  strategy  in  an  effort  to  reverse  the 
company's  sagging  performance. 

SCC  was  a  technology-driven  company  whose  major 
hardware  business  was  selling  mainframes  to  data  processing 
departments.  The  concept  of  end  user  computing  was  still 
relatively  unknown  in  1981,  and  the  emerging  personal 
computer  segment  of  the  market  was  not  regarded  as 
strategically  important  by  the  SCC  culture. 

Corporate  information  systems  (CIS),  was  the  firm's 
very  traditional,  centralized  DP  department.  The  head  of  CIS, 
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Warren  Zink,  had  no  secretary  and  operated  his  department 
with  a  primary  objective  of  keeping  costs  down.  This  strategy 
v.'as  traditional  in  CIS,  and  resulted  in  the  department 
running  the  oldest  mainframes  and  operating  systems 
available.  It  often  used  equipment  that  had  been  returned  by 
SCC  customers  for  newer  models.  Several  executives 
characterized  SCC's  internal  information  systems  as 
"archaic". 

Two  other  executives  joined  SCC  at  the  same  time 
Weathers  became  CEO.  Phillip  Dutton  was  named  executive  vice 
president  for  sales  and  marketing,  and  Richard  Brohammer 
became  chief  financial  officer. 

One  of  Weathers'  top  priorities  after  he  arrived  was 
to  change  SCC's  technology-focused  culture  and  its  product 
strategy,  and  he  saw  executive  support  systems  as  a  key  part 
of  this  plan.  Weathers  wanted  to  improve  productivity  at  the 
executive  level,  while  providing  a  laboratory  and  a  showplace 
for  new  product  development. 

In  addition  to  these  objectives,  the  CEO  felt 
personally  frustrated  by  the  lack  of  management  information 
that  was  available  to  him  to  run  the  company.  At  his  previous 
company  Weathers  had  a  terminal  on  his  desk  with  direct 
access  to  the  corporate  mainframe.  Not  only  did  he  now  feel 
he  did  not  have  enough  information,  but  the  CEO  also  believed 
the  corporate  controller  was  providing  the  existing 
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information  too  slowly. 

To  address  these  problems  Weathers  asked  one  of  SCC's 
r.ainf rame-oriented  product  development  groups  if  they  could 
help.  They  proposed  a  50-person  project  to  tackle  the  problem 
of  executive  support.  Weathers  looked  for  another  more 
practical  alternative  and  found  it  in  a  small  internal 
consulting  group  managed  by  Bill  Hatfield.  Hatfield,  who  had 
extensive  experience  as  an  internal  auditor  and  as  a  systems 
developer  in  CIS,  reported  directly  to  CFO  Richard  Brohammer. 

The  CEO  asked  Hatfield  and  his  group  of  senior 
consultants  to  develop  an  executive  support  system.  Hatfield 
agreed  and,  in  April  1982,  he  began  a  study  of  the 
information  currently  being  used  by  SCC's  senior  management. 
When  CIS  Manager  Warren  Zink  heard  about  the  project,  he 
urged  Weathers  and  Brohammer  to  shift  Hatfield's  reporting 
relationship  to  CIS.  Top  management,  however,  decided  that 
Hatfield  should  continue  to  report  to  the  CFO. 

In  July  1982,  Hatfield's  group  produced  a  report 
recommending  the  development  on  an  ESS  prototype  with  the 
ultimate  objective  of  providing  SCC's  500+  core  managers  with 
"user  friendly"  access  to  essential  performance  information. 
Top  management  had  put  two  constraints  on  any  system  Hatfield 
would  develop.  First,  it  had  to  be  capable  of  being  made 
secure  against  any  unauthorized  access.  Second,  only  SCC 
products  were  to  be  used  because  of  the  strategic  nature  of 
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the  system. 

Hatfield's  report  recognized  that  ESS  implementation 
would  require  support  staff  with  broad  exposure  to  business 
as  well  as  technical  competence  in  both  the  hardware  and 
software  used.  It  estimated  full  implementation  of  the  system 
would  take  15-20  months  and  argued  that  implementation  should 
be  done  by  a  small  group  which  would  report  directly  to  a 
senior  executive. 

The  report  presented  two  options  for  implementation. 
The  first  was  to  identify  critical  performance  factors  based 
on  the  company's  strategic  objectives  and  to  identify 
management  information  needed  to  support  them.  Hatfield 
explained  that  the  problem  with  this  option  was  that  Weathers 
had  only  recently  set  out  a  new  strategy  for  the  company,  and 
the  consultant  felt  he  couldn't  get  top  management  support 
for  entering  a  process  of  again  redefining  what  the  company 
was  about.  Hatfield  said  he  didn't  consider  the  option 
"politically  feasible." 

The  second  option  was  to  identify  current  planning 
activities  and  integrate  the  plans  and  actuals  data  currently 
used  in  those  activities  into  the  ESS  prototype.  Hatfield's 
report  acknowledged  that  the  drawback  of  this  approach  was 
that  it  relied  on  the  existing  plan  vs.  actual  data  to  design 
the  new  system,  even  if  they  were  not  what  should  be 
included.  Despite  this  drawback,  Hatfield's  group  chose  this 
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approach  when  the  CEO  approved  development  of  the  prototype. 
"We  were  looking  for  relatively  quick  results,  and  this  was 
the  pragmatic  approach,"  he  said. 

In  December  1982,  Hatfield's  group  returned  with  a 
prototype  ESS  that  used  SCC's  Lynx  terminal,  one  of  their 
most  successful  products.  After  a  demonstration  of  the  Lynx 
ESS,  Weathers  and  CFO  Richard  Brohammer  told  Hatfield  to 
produce  the  prototype  and  install  it  in  the  offices  of  the 
corporation's  14  senior  managers.  Using  the  Lynx  terminal, 
the  system  would  be  networked  to  a  mainframe  at  the  firm's 
data  center  20  miles  from  corporate  headquarters. 

Lvnx  Design  and  Installation 

r 

In  March  1983,  Malcolm  Livingston  was  named  the  new 
manager  of  CIS,  replacing  Zink,  who  left  the  company. 
Livingston  was  chosen  over  Hatfield  who  had  made  a  bid  for 
the  job. 

Soon  afterwards,  in  a  move  that  Weathers  did  not 
consider  significant,  CFO  Richard  Brohammer  shifted 
Hatfield's  reporting  relationship  to  Livingston.  The  CFO  said 
he  did  not  have  enough  time  to  manage  Hatfield  properly. 
Hatfield  had  a  very  uneasy  relationship  with  his  new  boss, 
whom  he  thought  ran  CIS  "like  a  batch  computing  bureau." 
Hatfield  said: 
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Shifting  my  reporting  relationship  to 
Livingston  affected  the  visibility  of  my  group. 
Livingston  pretty  much  gave  me  free  reign,  but  I 
lost  some  of  the  direction  I  had  been  getting  from 
Weathers  and  Brohammer.  I  think  some  of  the 
inspirational  direction  from  Weathers  started  to 
decline  because  he  assumed  Livingston  was  providing 
it.  But  he  wasn't. 


Through  the  spring  of  1983 ,'  Hatfield1 s  group  spent 
time  trying  to  overcome  technical  problems  with  the  mainframe 
operating  system  the  Lynx  terminals  would  be  using.  Among  the 
problems  the  development  group  faced  was  a  lack  of 
applications-oriented  software  suitable  for  executives  and  a 
very  unfriendly  operating  system,  which  was  difficult  to  log 
into.  As  technical  problems  continued  to  plague  the  project 
and  as  the  design  process  progressed,  it  became  clear  to 
Hatfield  that  his  group  was  going  to  spend  more  time  on 
technical  rather  than  business  issues. 

"As  a  result,"  he  said,  "we  didn't  approach  the 
project  from  a  full  understanding  of  how  the  system  would  be 
used.  Rather  our  purpose  was  just  to  help  share  more 
information  among  the  executives." 

But  even  the  task  of  providing  information  proved  more 
difficult  than  expected.  Hatfield  had  a  very  difficult  time 
getting  the  corporate  controller  to  release  information  for 
the  system.  "We  represented  a  challenge  to  the  corporate 
staffs,  and  the  controller  was  upset  at  the  idea  of  the  CFO 
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coming  to  us  for  information,"  Hatfield  said. 

The  controller's  primary  argument  for  not  releasing 
information  for  the  Lynx  system  was  security.  His  concerns, 
however,  were  not  unjustified.  SCC  had  gone  through  a  very 
embarrassing  experience  several  years  previous  when  some  of 
the  company's  confidential  financial  information  inexplicably 
had  appeared  in  a  local  newspaper.  That  experience  made  the 
finance  department  extremely  cautious  about  releasing  data  to 
anyone. 

By  the  summer  of  1983,  Lynx  terminals  had  been 
installed  on  the  desks  of  13  senior  executives.  (The  vice 
president  of  personnel  refused  to  allow  one  in  his  office, 
contending  he  had  no  use  for  it.)  Hatfield  and  his  three 
consultants  showed  each  executive  the  capabilities  on  the 
system  and  then  asked  them  how  they  would  like  to  use  it.  The 
system  had  a  menu  with  five  applications  directly  available, 
including  corporate  performance  summaries  and  modeling. 
Technical  problems,  however,  continued  to  make  the  software 
difficult  to  learn  and  use.  For  example,  different  packages 
required  different  "log  off"  procedures  and  data  was 
outdated.  As  a  result,  the  Lynx  system  was  all  but  ignored  by 
executives  shortly  after  it  was  introduced,  even  though 
Hatfield's  group  continued  to  try  to  enccourage  its  use  for 
some  time.  Marketing  EVP  Phillip  Dutton  described  his 
reaction  to  SCC's  first  ESS: 
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Initially,  it  was  going  to  be  a  product  that 
we  could  network  together  and  put  up  a  financial 
database,  so  I  could  get  into  it  and  look  at 
instantaneous  trends,  results,  etc.  But  the  network 
didn't  work  very  well  and  it  kept  breaking  down,  so 
the  system  wasn't  up  a  lot.  Also,  because  it  was  a 
special  project,  the  system  was  always  late  getting 
the  data  loaded  onto  it,  so  the  data  was  always  out 
of  date.  After  finding  the  system  out  of  date  or 
broken  a  few  times,  then  I  just  began  referring 
back  to  the  printed  reports. 

It  was  also  a  terrible  job  to  get  through 
the  security  system.  Security  was  a  major  issue 
because  the  controller  was  fanatical  about  it.  He 
made  damn  sure  that  the  system  went  through  the  nth 
level  of  security.  But,  in  the  end,  it  would  take 
the  normal  ad  hoc  user  ten  minutes  to  get  through 
the  security  section. 


In  the  end,  there  was  a  lot  of  interest  but  no  direct 
use  by  the  executives  themselves,  conceded  Hatfield.  To  get 
at  a  particular  "what  if",  the  executives  would  actually  get 
a  staff  member  to  operate  the  terminal  for  them. 

Reorganization 

In  May  1983,  Weathers  began  a  major  reorganization 
within  SCC.  The  product  development  and  marketing  people  were 
integrated  into  15  product  centers  each  with  a  product  line 
or  industry  focus,  such  as  mainframes,  insurance  industry,  or 
the  federal  government.  The  product  centers  defined  markets 
and  developed  the  products/services  to  be  brought  to  those 
markets  and  sold  by  the  geographically  organized  sales  units. 
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The  Management  Support  Product  Center  (MSPC)  was 
created  to  develop  and  market  products  related  to  DSS/ESS, 
knowledge  engineering,  and  business  graphics.  MSPC  was  headed 
by  Walter  Edison. 

Earlv  Development  of  PC-based  ESS 

For  some  time,  Weathers  had  been  pressing  MSPC 
management  to  get  an  ESS  product  into  the  marketplace,  and 
simultaneously,  he  and  Brohammer,  the  CFO,  were  still  looking 
for  something  to  support  SCC  executives.  CIS  remained 
responsible  for  implementing  any  internal  systems  for  top 
management.  CIS  had  to  rely  on  the  product  centers,  however, 
to  do  the  actual  hardware  and  software  development  for  ESS, 
which  would  also  ultimately  be  sold  as  products  in  the 
external  marketplace. 

Meanwhile,  product  developers  in  MSPC  felt  unusual 

pressure  to  deliver  something  through  CIS  because  Weathers 

had  made  it  clear  he  wanted  a  system  on  his  desk  "tomorrow." 

It  was  decided  that  the  capabilities  of  the  new  ESS  would  be 

based  on  external  market  research  done  previously  by  MSPC.  No 

interviews  were  done  inside  SCC.  Arthur  Frost,  who  was  in 

charge  of  ESS  product  development  for  MSPC,  explained: 

The  key  lesson  from  the  research  was  the  need 
for  relevance  to  the  executive's  job.  Provided  you 
gave  them  what  they  needed,  a  surprising  number  of 
executives  were  prepared  to  deal  with  complex 
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interfaces.  We  also  concluded  that  executives 
wanted  access  to  many  capabilities  at  once,  and  the 
ability  to  switch  tasks  and  information  sources 
quickly.  This  meant  we  had  to  put  a  lot  of 
intelligence  on  their  desks.  Also,  we  were  up 
against  a  very  short  time  scale  because  Weathers 
had  given  us  a  deadline,  which  meant  we  couldn't 
design  something  new.  We  had  to  use  existing 
equipment. 

Hatfield's  Lynx  system  was  not  ready  to  market  and 
lacked  the  local  processing  capabilities  MSPC  wanted,  so 
Frost  began  looking  outside  to  see  what  high  quality  graphics 
terminal  could  be  brought  into  SCC.  The  decision  was  made  to 
use  an  intelligent  color  monitor  built  by  a  Japanese  company, 
which  could  be  linked  to  SCC's  own  recently-developed 
personal  computer  (PC) .  The  PC  offered  more  local  processing 
power  than  the  Lynx  for  individual  applications,  and  using 
the  Japanese-built  monitor  would  give  SCC  the  chance  to 
market  its  first  color  graphics  terminal. 

Frost  conceded  that,  from  the  start  of  the  PC 
development  project,  things  didn't  move  as  fast  as  expected. 
But,  because  of  the  continuing  pressure  from  Weathers,  MSPC 
introduced  a  prototype  of  the  ESS  product  to  top  management 
in  October  1983.  The  developers  had  adapted  some  of  the 
software  technology  from  the  Lynx  system  and  created  a 
generalized  menu  system  that  could  be  personalized  for 
individual  users.  Walter  Edison,  head  of  the  Management 
Support  Product  Center,  introduced  the  PC  system  prototype  of 
what  MSPC  planned  to  market  as  DSS  for  executives.  The  system 
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included  a  graphics  package,  called  "Giraffix,"  which  was 
designed  to  create  graphics  on  the  PC  once  data  was 
downloaded  from  the  mainframe. 

Decision  Support  Group  ' Desk i 1 1 ed ' 

Since  Hatfield's  team  of  consultants  had  been 
reassigned  to  CIS,  they  had  become  known  as  the  Decision 
Support  Group  (DSG) .  Their  primary  responsibility  continued 
to  be  encouraging  and  supporting  top  management  computer  use. 
By  August  1983,  Hatfield  had  begun  to  taken  on  broader 
responsibilities  within  CIS,  so  he  brought  in  Jill  McMahon  to 
manage  the  Decision  Support  Group.  McMahon,  whose  primary 
strengths  were  in  technical  areas,  was  told  the  DSG's  target 
population  was  the  top  20  executives.  Virtually  no  progress 
was  made,  however,  in  developing  Lynx  use  among  executives 
between  August  and  October,  in  part,  because  of  communication 
problems  that  existed  in  trying  to  operate  the  ESS  on  a 
remote  mainframe  in  the  corporate  data  center.  The  system 
seemed  to  be  "gathering  dust"  on  most  executive's  desks. 

In  November,  DSG  was  set  up  with  access  to  half  a  new 
mainframe  at  corporate  headquarters  in  anticipation  of  its 
hardware  needs  for  supporting  top  management  in  the  future. 
But  other  things  were  happening  to  DSG  that  reduced  its 
ability  to  support  SCC  executives.  "Weathers  wanted  to 
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deskill  DSG  activities  so  the  group  could  be  run  by  only  four 
junior  people,"  said  Hatfield. 

He  explained  that  until  McMahon  took  over  the  DSG  in 
August  there  had  been  three  senior  consultants  involved  in 
the  ESS  activities  who  were  used  to  dealing  with  top 
management.  While  three  senior  people  could  support  more 
executives,  Hatfield  said  that  McMahon,  with  her  staffing  now 
restricted  to  junior  people,  could  not  cope  with  supporting 
more  than  a  couple  of  top  managers.  By  late  1983,  DSG  was 
staffed  with  two  analysts  and  two  programmers. 

"We  had  junior  people  trying  to  provide  support  to 
Weathers.  They  just  couldn't  do  it,"  said  Hatfield.  "In 
retrospect,  I  leaned  too  far  on  technical  expertise." 

PC  System  Development 

Weathers  was  upset  when  the  MSPC  had  not  delivered  its 
new  PC-based  executive  support  system  by  early  1984.  As  a 
result,  CFO  Richard  Brohammer  met  in  early  February  with  CIS 
Manager  Malcolm  Livingston,  Hatfield  and  McMahon  to  discuss 
the  problem  and  make  sure  everything  possible  was  being  done 
to  get  the  product  out.  At  the  meeting,  Brohammer  expressed 
doubts  that  Walter  Edison's  product  center  was  going  to  be 
able  to  develop  the  PC-based  ESS  software  on  schedule, 
despite  pressure  from  Weathers. 
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Thus  some  decisions  were  made.  Brohammer  told  the  CIS 
people  that  he  wanted  a  new  ESS  terminal  implemented  for  the 
top  three  people  in  SCC  (Weathers,  Brohammer  and  Dutton) ,  and 
the  CFO  would  decide  what  would  be  on  the  system.  Brohammer 
then  looked  at  what  they  could  deliver  in  short  order.  He 
reviewed  the  original  Lynx  menu  and  said  he  wanted  corporate 
performance  summaries,  inter-company  comparisons,  the  five 
year  planning  model,  and  some  product  line  profitability 
statements  in  the  PC-based  system. 

Marketing  EVP  Phillip  Dutton  offered  this  perspective 
on  Brohammer 's  decision  to  get  involved  in  the  ESS 
development: 

Primarily,  I  think,  he  wanted  to  get  a 
system  that  would  work  and  deliver  things  that  he 
needed  and  not  have  all  these  different  folks 
involved.  He  was  primarily  concentrating  on  the 
financial  reporting  parts  of  the  system  that  he 
needed. 

At  that  stage  we'd  had  a  lot  of 
non-progress,  so  Brohammer  picked  up  the  baton  to 
get  some  system  out  so  we  could  get  at  our  own  data 
and  also  use  it  to  show  customers  what  innovative 
people  we  were. 

Hatfield  explained  the  design  problems  that  remained 

for  CIS  and  the  product  centers: 

Despite  Brohammer 's  plans  and  the  summer 
installation  deadline,  as  of  February,  the  PC  was 
not  yet  actually  available,  and  the  graphics,  LAN, 
and  applications  software  was  still  in  development. 
None  had  been  field  tested  or  released  as  products. 
Thus,  we  were  working  to  a  time  scale  which 
effectively  said,  'We  expect  to  get  software  at  X 
point  and,  meanwhile,  the  graphics  are  being 
developed  and  we  hope  the  two  will  work  together.' 
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After  the  meeting  with  Brohammer  made  it  clear  the  PC 
project  was  top  priority,  a  series  of  weekly  meetings  were 
set  up  between  DSG  people  in  CIS  and  those  in  the  product 
centers  involved  with  PC/ESS  development.  The  weekly  meetings 
went  on  until  July  but,  despite  the  pressure  from  top 
managment,  the  project  slipped  almost  a  month  behind  schedule 
because  the  software  was  still  not  available,  said  Hatfield. 

Arthur  Frost,  ESS  project  manager  for  MSPC,  offered 
this  perspective  on  the  process: 

Not  only  did  lots  of  technical  problems 
arise  in  the  meetings  with  CIS,  but  personality 
clashes  among  those  involved  added  to  the  tension. 
We  were  shouting  at  each  other  a  lot. 

The  people  from  CIS  were  looking  after 
senior  management  and  their  views  of  what  the 
system  should  do  were  often  at  variance  with  our 
views.  At  the  weekly  meetings  it  became  clear  that 
SCC's  top  executives  were  very  different 
individuals  with  different  requirements  and  needs, 
attempting  to  be  satisfied  with  a  single  product. 
Weathers  was  happy  with  a  keyboard,  easily 
understood  it,  and  could  do  complex  things  on  the 
system.  Brohammer  expected  that  when  the  system  was 
switched  on  it  would  automatically  show  yesterday's 
sales  results.  Other  executives  were  more  normal 
and  as  casual  users  needed  something  that  was 
simple  and  clearly  labelled. 

In  July  1984,  a  meeting  was  held  to  demonstrate  the 
progress  made  on  the  PC-based  ESS.  Among  those  attending  were 
Livingston,  Hatfield,  Brohammer,  Edison,  and  a  consultant  who 
had  been  brought  in  to  help  keep  the  ESS  project  on  track. 
Weathers  showed  up  at  the  meeting  unexpectedly. 

McMahon  demonstrated  how  the  PC  could  do  modeling  on 
the  mainframe  and  produce  graphics  on  the  PC.  Weathers 
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watched  the  demo  and  told  Edison,  whose  group  had  developed 
the  software,  that  the  PC  was  too  slow  in  generating 
graphics. 

The  consultant  had  a  similar  reaction.  "It  was 
painfully  slow  and  too  awkward  to  use.  Too  many  keystrokes 
were  needed.  If  I  had  work  to  do,  I  couldn't  work  at  that 
speed,"  he  said. 

Despite  his  criticism  of  the  PC's  slowness,  Weathers 
was  encouraging.  "OK,  you've  got  something  there.  Now  what 
are  you  going  to  do  with  it?"  he  asked.  "I  want  to  spread 
this  around  to  the  executive  staff,  and  we  should  be  using  it 
in  the  product  centers  to  improve  their  access  to  management 
information."  Weathers  then  turned  to  Livingston  and  asked, 
"How  many  are  you  proposing  to  install  this  year?" 

The  CIS  manager  hesitated  for  a  moment  and  then 
responded,  "We've  got  a  budget  for  40." 

Thus  it  was  agreed  that  CIS  would  install  40  PCs  —  20 
in  the  corporate  offices  and  20  among  executives  in  the 
product  centers  —  as  soon  as  possible.  This  became  known  as 
the  "40  PC  project." 

Dutton,  sales  and  marketing  EVP,  offered  this  view  of 
the  decision  to  implement  40  PCs  for  executives:  "Weathers 
made  an  emotional  decision  that  we  had  to  get  PCs  on  people's 
desks.  It  was  one  of  those  gut  feels.  Get  people  more 
involved  in  what  sits  on  their  desks,  then  worry  about  what 
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they're  going  to  use  it  for." 

Shortly  after  the  "40  PC  project"  was  initiated  a 
major  change  hit  SCC.  The  company  merged  with  Electronics 
International  Group  (EIG) ,  a  large  multi-national 
corporation.  This  led  to  a  top  management  shakeup.  Weathers 
became  chairman  of  the  SCC  subsidiary  and  a  senior  executive 
in  EIG.  In  September  1984 ,  EVP  Phillip  Dutton  became 
president  of  SCC.  Shortly  afterwards,  Brohammer  left  the 
company  and  a  new  CFO  was  named. 

PC  Installation 

PCs  were  installed  in  the  offices  (and  some  homes)  of 
SCC's  executives  during  the  fall  of  1984.  Use  of  the 
technology  by  top  management  varied  significantly,  and 
depended  a  great  deal  on  each  manager's  particular  function 
and  work  style. 

Weathers'  commented  on  his  own  experience  and  needs  for 
computer  support  as  SCC's  chairman: 

So  far  they  have  been  unable  to  provide  me 
with  support  where  I  need  it,  such  as  at  home.  CIS 
came  out  with  a  bunch  of  junk  which  was  so  awful  I 
sent  it  back.  It  was  a  PC  with  a  modem,  but  it 
covered  the  whole  desk. 

What  I  need  primarily  is  facsimile, 
electronic  mail,  voice  mail,  and  all  the  instant 
messaging  capabilities;  also,  competitive 
assessment  analysis,  industry  news,  and,  lastly, 
financial  information  about  our  own  activities.  I 
think  that's  the  difference  between  senior  people 
who  tend  to  look  at  an  industry  from  a  strategic 
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overview  and  line  managers  who  are  deeply  engrossed 
in  their  own  financial  activities. 

When  CIS  installed  Dutton's  PC,  the  new  president 

found  the  experience  not  unlike  the  one  he  had  with  the  Lynx 

system  earlier. 

Guys  came  up  and  I  had  about  two  45  minute 
training  sessions.  That  was  adequate  to  get  going, 
but  getting  past  the  security  checks  was  still  a 
problem,  although  it  was  easier  than  with  the  Lynx. 
More  important,  the  data  was  not  useful  enough  for 
me  to  really  want  to  spend  a  lot  of  time  getting 
into  the  system.  It  was  still  often  a  month  out  of 
date. 

We  were  putting  more  management  effort  into 
that  so-called  decision  support  system  than  we  were 
on  trying  to  figure  out  how  we  could  get  our  data 
faster,  regardless  of  what  format  it  was  in.  We 
were  busy  looking  at  the  graphics  and  how  to  get  it 
up  onto  screens,  and  how  the  LAN  system  worked, 
when,  in  fact,  all  the  data  we  were  looking  at  was 
three  weeks  out  of  date. 

So,  our  priorities  were  in  the  wrong  place. 
What  we  should  have  been  doing  is  spending  all  of 
our  management  effort  making  sure  that  we  could  do 
the  consolidations  in  two  days,  and  then  figure  out 
how  to  use  it. 

The  primary  function  of  the  vice  president  for 

technology  planning  is  to  make  decisions  about  R&D 

investments.  He  commented  on  his  experience  with  the  PC-based 

ESS: 

My  hackles  were  up  even  before  the  system 
arrived.  There  was  no  way  I  was  going  to  have  a 
system  someone  told  me  I  must  have.  I  publicly  made 
a  point  of  how  hard  it  was  to  turn  on  and  to  get 
the  system  up,  and  the  response  time  was  pretty 
awful.  Also  there  were  some  real  problems  with  the 
command  structure.  The  screen  would  say  press 
button  X  to  do  something  when  really  you  were 
supposed  to  press  button  Y. 

Early  on  I  made  a  nuisance  of  myself  saying 
I  don't  want  a  package.  Instead,  I  said  I  wanted  an 
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R&D  project  monitoring  system,  but  CIS  couldn't 
make  the  system  flexible  in  that  way.  They  tried  to 
create  a  single  package  everyone  would  use,  but 
they  forgot  that  we  all  wanted  to  do  something 
different.  The  fact  that  getting  new  capabilities 
took  six  months  was  too  long. 

Besides,  the  bulk  of  my  job  is 
communication,  not  analysis.  My  real  need  is  for 
communications  support  between  me  and  my  staff. 
Very  little  information  for  decision  making  in  my 
job  is  financially  based.  Most  of  the  information  I 
use  is  highly  subjective,  and  at  least  50  percent 
of  it  is  external.  So,  basically,  my  systems  needs 
are  for  electronic  mail,  the  ability  to  build 
customized  systems,  and  for  visibility  into  some  of 
our  existing  operational  systems. 

The  vice  president  of  SCC's  Office  Systems  Division  is 

responsible  for  five  product  centers,  including  the  PC 

product  center.  He  said  he  spends  half  his  time  managing  the 

product  centers  and  the  other  half  on  corporate  business  not 

directly  concerned  with  the  division.  He  described  his 

experience  as  follows: 

I  have  a  double  interest  in  the  PC.  It  is 
one  of  my  products  and  I  want  to  use  it  for 
corporate  I/S.  My  PC  is  at  home,  though,  because 
I'm  never  in  the  office.  When  I  said  I  wanted  it  at 
home  that  created  a  problem.  I  have  an  encrypting 
modem  which  is  expensive  and  difficult  to  set  up, 
but  that's  because  the  controller  wouldn't  allow 
data  out  of  the  mainframe  without  encrypting  it. 

The  main  thing  I  use  it  for  is  typing  longer 
documents,  such  as  a  talk  or  a  strategy  paper.  I 
print  it  at  home  and  get  it  rekeyed  at  the  office 
because  I  can't  squirt  it  into  electronic  mail. 
I've  got  electronic  mail,  but  it's  extremely 
unfriendly. 

I  also  use  the  PC  to  go  into  the  corporate 
databases  to  look  at  company  and  unit  results.  But 
I  do  this  out  of  a  sense  of  duty.  I  find  the  system 
clumsy  to  get  into.  You  need  three  different 
passwords.  But  the  real  problem  is  there  is  nothing 
new  in  the  data  base.  Corporate  finance  doesn't 
want  to  put  anything  in  the  data  base  until  it  has 
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been  presented  at  the  monthly  forecast  meeting.  As 
a  result,  they  don't  put  data  in  until  it's  too  old 
to  be  useful,  so  I  never  learn  anything  new  from 
the  system.  Access  to  paper  reports  is  faster. 

I  spend  70  percent  of  my  time  in  reviews  and 
meetings,  and  I'm  in  my  office  less  than  10  percent 
of  the  time.  When  I  do  come  in  it  is  for  a  stack  of 
tightly  processed  discussions.  My  time  is  tightly 
programmed.  I  do  about  18  hours  of  reading  a  week, 
but  almost  always  out  of  the  office.  For  most  of 
the  stuff  I  read  I  attach  a  note  with  the  action  to 
be  taken.  Electronic  mail  wouldn't  work  for  this. 

Logistics  is  critical.  Anything  I  can  do  to 
save  time  will  give  me  more  time  for  planning. 
Otherwise,  I'm  rushing  from  one  pile  of  paper  to 
another  and  from  meeting  to  meeting. 

CIS  continued  to  install  ESS  applications  on  the  PCs 

sitting  on  the  desks  of  SCC's  top  managers  through  December 

1984.  On  January  8,  1985,  almost  three  years  after  Weathers 

had  first  asked  Hatfield  to  implement  an  ESS,  President 

Phillip  Dutton  sent  a  memo  to  CIS  manager  Malcolm  Livingston 

and  MSPC  manager  Walter  Edison.  These  were  the  two  people 

currently  responsible  for  SCC's  executive  support  systems. 

Dutton  wrote: 

I  have  a  decision  support  system  hooked  up 
in  my  office  which  I  can  assure  you  I  never  use. 
...If  I  weren't  such  an  optimist,  I  would  despair. 
Please  let  me  know  when  I  can  have  something  which 
is  useful  to  me  in  my  office. 
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SJQHfi  COMPUTER  CORP.  AND  LESSONS  TN  ESS  IMPLEMENTATION 

Let  us  look  at  Stowe  Computer  Corporation's  experience 

in  light  of  the  eight  factors  in  ESS  implementation  outlined 

earlier.  How  does  the  Stowe  case  illustrate  the  issues 
identified? 

1.  A  Committed  and  Informed  Executive  Sponsor 

In  our  research,  rarely  did  we  find  an  ESS  being  used 
by  executives  that  had  been  initiated  solely  by  the 
information  systems  department.  Executive  users  must  want  and 
ask  for  the  system  themselves.  There  are  three 
characteristics  the  executive  sponsor  must  have.  First,  he  or 
she  must  be  committed  to  putting  time  and  energy  into  the  ESS 
project.  Second,  the  sponsor's  expectations  of  what  is 
possible  for  the  system  must  be  in  line  with  the  physical 
limitations  of  the  technology  and  data  access. 

Finally,  the  sponsor  should  have  a  realistic 
understanding  of  the  implementation  process  itself  and  what 
the  organization  must  go  through  to  develop  an  effective  ESS. 
The  executive  must:  (1)  understand  the  human  and  financial 
resources  needed  for  the  project;  (2)  recognize  the  need  for 
an  operational  sponsor;  (3)  anticipate  the  organizational 
impacts  of  the  system;  and  (4)  anticipate  and  deal  with 
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political  resistance  to  the  system's  perceived  impacts. 

SCC's  executive  support  project  clearly  had  a  sponsor 
in  CEO  Roger  Weathers.  Weathers  wanted  the  system  and  was 
willing  to  spend  time  seeing  that  it  was  developed.  But  it 
was  also  important  for  the  executive  sponsor  to  have  a 
realistic  expectation  of  both  the  ultimate  capabilities  of 
the  system  and  the  organizational  issues  surrounding  the 
implementation  process.  Weathers  seemed  to  lack  both  of 
these,  although,  in  his  defense,  a  desire  to  have  the  firm 
learn  about  the  implementation  process  was  one  of  the  reasons 
he  encouraged  the  ESS  projects  in  the  first  place. 
Nevertheless,  the  predictable  shortcomings  of  an  ESS 
developed  in  this  setting  created  frustration  and 
disillusionment  for  the  chief  executive. 

2.  An  Operating  Sponsor 

The  task  of  managing  ESS  development  is  frequently, 
but  not  always,  delegated  to  a  trusted  subordinate  who 
becomes  the  "operating  sponsor"  (Levinson,  1984) .  This 
sponsor  ideally  is  a  person  who  can  communicate  easily  with 
both  the  executive  user  and  the  ESS  designers.  He  or  she 
serves  as  a  go  between  helping  to  match  business  needs  with 
technological  capabilities.  Quite  often,  where  the  CEO  is  the 
executive,  or  initiating,  sponsor,  the  task  of  operating 
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sponsor  often  falls  to  the  CFO  or  the  controller. 

In  the  SCC  case,  the  CFO  assumed  the  role  of  operating 
sponsor  at  times,  particularly  with  the  PC  project.  Before 
that,  however,  he  had  delegated  away  the  operating  sponsor's 
role  when  he  shifted  Bill  Hatfield's  reporting  relationship 
to  the  CIS  manager.  When  that  happened,  the  input  Hatfield 
received  from  top  management  was  diminished  because  he  was 
reporting  to  the  CIS  manager,  not  the  CFO,  and  his  project 
came  to  be  viewed  as  "just  another  DP  function." 

In  general,  the  SCC  case  is  an  example  of  a  lack  of 
clarity  about  sponsors'  roles  and  shows  the  confusion  that 
can  arise  when  the  role  of  operating  sponsor  is  not  made 
explicit  and  is  filled  only  intermittently. 

3.  Clear  Link  to  Business  Obiective(s) 

The  irony  of  ESS  is  that  often  executives  demand 
systems  on  what  seems  like  such  short  notice  that  defining 
the  business  objective  of  a  system  is  probably  the  most 
frequently  ignored  activity  in  the  implementation  process.  It 
is  assumed  the  executive  is  too  impatient  to  go  through  such 
analysis,  the  ESS  developers  are  too  afraid  to  ask  for  such 
input,  or  the  developers  don't  consider  it  important  to 
identify  a  link  between  specific  business  needs  and  the 
technology.  As  a  result,  the  systems  usually  do  not  take  full 
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advantage  of  the  unique  benefits  the  technology  could 
provide,  such  as  faster  access  to  data  or  more  effective 
communications. 

Weathers  identified  a  need  for  the  system  on  several 
levels:  (1)  to  increase  his  own  access  to  information;  (2)  to 
improve  executive  productivity;  and  (3)  to  develop  an  ESS 
product  for  the  marketplace.  Not  only  are  these  multiple 
objectives  in  conflict  with  each  other,  but  they  are  also  too 
vague  to  be  useful  in  linking  the  technology  to  internal 
business  problems.  In  this  case,  Weathers  seemed  most 
concerned  about  getting  an  ESS  product  to  the  marketplace, 
while  SCC's  CFO  Richard  Brohammer  was  pushing  CIS  for  a 
system  that  would  meet  the  needs  of  his  finance  function. 
Thus,  the  ESS  developers  were  getting  mixed  signals  from  the 
initiating  sponsor,  Weathers,  and  Brohammer,  who  at  times 
acted  as  the  operating  sponsor. 

In  the  case  of  the  Lynx  ESS,  Hatfield  actually  decided 
the  system's  capabilities  because  he  found  it  so  difficult  to 
get  executive  input.  He  conceded  that  his  group  did  not 
actually  know  what  the  system  would  be  used  for.  Their  only 
objective  was  to  help  executives  share  information  better. 
Unfortunately,  this  was  not  an  important  business  objective 
for  top  management.  For  the  PC-based  ESS  project,  the  CFO 
dictated  the  applications.  In  this  case,  the  only  business 
objectives  the  CFO  had  in  mind  were  those  of  his  finance 


-29- 


function,  to  the  dismay  of  other  executives. 

A  result  of  the  failure  to  explicitly  link  the 
technology  to  business  objectives  in  both  situations  was  that 
neither  system  met  the  needs  of  the  executives  who  were  given 
terminals.  Weathers,  for  example,  made  it  clear  that  his 
needs  were  primarily  in  the  communications  area,  as  did  the 
vice  president  of  technology  planning.  Yet,  the  electronic 
mail  package  on  the  PC  system  was  universally  criticized  by 
the  executives  as  terribly  unfriendly  and  totally  unusable. 

4.  Appropriate  I/S  Resources 

Weathers  chose  Bill  Hatfield's  small  team  of 
experienced  consultants  to  implement  an  ESS  over  the 
monolithic,  mainframe-oriented  product  development  group  that 
wanted  to  make  it  a  50-person  project.  In  many  ways,  Hatfield 
was  the  ideal  person  to  fill  the  critical  role  as  ESS  project 
manager  on  the  I/S  side.  Not  only  had  he  been  a  systems 
developer  in  CIS,  but  he  also  had  extensive  business 
experience  managing  the  firm's  internal  audit  group.  He  was  a 
good  communicator  and  was  viewed  as  very  professional  by  SCC 
executives.  One  drawback  was  that  he  never  had  a  good 
relationship  with  the  head  of  CIS. 

Hatfield's  decision  to  bring  in  someone  to  replace  him 
in  running  the  Decision  Support  Group  who  had  a  technical 
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rather  than  a  business  orientation  was  an  unfortunate  move. 
Hatfield's  ability  to  understand  business  executives  and  to 
communicate  with  them  was  lost.  This  shift  to  a  more 
technical  orientation  happened  as  Weathers  was  reportedly 
trying  to  "deskill"  DSG.  Reducing  the  quality  of  the  support 
staff  from  senior  consultants  with  a  business  orientation  to 
more  technically-oriented  junior  analysts  unable  to  relate  to 
top  management  was  a  costly  mistake. 

It  is  also  worth  noting  that  Hatfield's  group  existed 
outside  the  mainstream  operations  of  CIS,  reporting  instead 
directly  to  the  CFO.  Our  research  has  shown  this  to  be  not  an 
unusual  pattern.  Often,  a  traditional  I/S  department  just 
does  not  have  the  flexible,  fast  moving,  sophisticated 
mindset  needed  to  support  executive  users.  ESS  development 
teams  are  often  composed  of  people  like  Hatfield  who  come 
from  the  finance  department  and  who  also  have  I/S  experience. 
Being  outside,  or  on  the  fringe  of  the  I/S  department, 
however,  can  make  it  very  difficult  for  ESS  developers  to  get 
access  to  I/S  resources  because  of  political  infighting. 

5.  Appropriate  Techno! nay 

Although  the  ESS  developers  had  to  use  SCC's  own 
products,  it  is  not  unusual  for  companies  to  have  their  ESS 
hardware  choices  predetermined  because  one  vendor  dominates 
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the  firm  already.  This  explains,  in  part,  the  overwhelming 
predominance  of  IBM  PCs  that  were  found  on  executives'  desks 
in  our  1984  study  of  45  Fortune  500  companies 
(De  Long/Rockart) . 

The  major  technology  decisions  are  usually  in  the 
software  area.  Many  common  problems  with  existing  software 
are  evident  in  the  SCC  case: 

— Software  packages  cannot  be  integrated  easily. 

— Operating  systems  do  not  allow  multi-tasking. 

— Response  time  is  too  slow  (sometimes  a  hardware 
problem) . 

— Complex  command  structures  make  systems  hard  to 
learn  and  remember. 

— Extensive  menus  make  the  software  easier  to  learn, 
but  difficult  to  use  quickly  once  they  are  mastered. 

Often  the  capabilities  of  existing  software  —  rather 
than  user  needs  —  determine  the  applications  built  into  an 
ESS.  What  is  presented  to  the  user  is,  too  often,  crammed 
into  what  the  software  can  deliver.  Attempts  to  tailor  a 
system  to  specific  user  needs  often  create  a  dilemma  for 
developers.  They  are  caught  between  users  who  want  systems 
today  and  the  realities  of  slow  moving  software  development 
projects. 

Response  time  is  a  common  technology  problem  that  must 
be  anticipated.  Our  research  shows  that  executives  simply 
will  not  use  systems  when  response  time  is  more  than  a  couple 
of  seconds.  The  paradox  is  that  when  a  system  is  initially 
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successsful  and  response  time  is  good,  more  users  inevitably 
want  to  get  on  the  system.  As  a  result,  response  time,  unless 
it  is  well  managed,  can  deteriorate  and  badly  undermine  the 
value  of  the  system. 

Compatability  with  existing  systems  is  yet  another 
issue,  and  like  the  problems  above,  it  too  surfaced  in  the 
SCC  case.  Note  that  the  SCC  executives  could  not  communicate 
with  their  secretaries'  terminals.  This  is  a  frequent  problem 
and  one  that  needs  consideration  before  technology  choices 
are  made  because  the  executive-secretary  link  is  critical. 

6.  Management  of  Data  Problems 

Anticipating  data  management  problems  was  clearly  not 
done  in  the  SCC  case,  and  it  becomes  evident  in  the  comments 
of  Dutton  and  the  vice  president  of  the  office  systems 
division.  Dutton  pointed  out  that  the  fundamental  problem  was 
not  the  ESS  design,  but  the  fact  that  it  took  the  company 
three  weeks  to  close  its  books.  He  believed  management  effort 
would  have  been  better  spent  trying  to  improve  the  firm's 
consolidation  system,  instead  of  trying  to  develop  an  ESS. 

The  office  systems  division  vp  raised  another  data 
management  problem.  Corporate  finance  would  not  release  data 
for  the  ESS  until  it  had  been  presented  at  the  monthly  review 
meeting.  This  meant  the  data  was  effectively  out  of  date  by 
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the  time  it  got  on  the  system.  This  raised  an  important 
question.  At  SCC,  who  owned  the  financial  data  —  corporate 
finance  or  the  company? 

ESS  implementation  frequently  raises  questions  of  data 
ownership.  To  be  of  value,  an  ESS  must  provide  data  faster 
than  traditional  paper-based  systems,  but  that  means  changing 
existing  information  flows  and,  thus,  the  distribution  of 
power. 

7.  Management  of  Organizational  Resistance 

Executive  support  systems,  to  be  effective,  must 
change  information  flows,  improving  the  timeliness,  the  type, 
and  the  quality  of  the  information  users  receive.  Shifting 
information  flows  inevitably  means  threatening  the 
distribution  of  power  in  an  organization.  This  potential 
power  shift  will  almost  always  be  met  by  political 
resistance.  There  are  several  examples  of  political 
resistance  in  the  SCC  case. 

CIS  management  did  not  like  Hatfield's  ESS  development 
team  operating  outside  of  their  department,  and  they 
continually  lobbied  the  CFO  to  shift  that  reporting 
relationship.  Finally,  Brohammer  agreed,  and  when  Hatfield's 
group  was  reassigned  to  CIS,  it  lost  a  significant  amount  of 
the  prestige  it  had  in  reporting  directly  to  the  CFO. 
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Hatfield  found  it  very  difficult  to  get  the  corporate 
controller  to  release  financial  data  for  use  in  the  ESS.  The 
controller's  justification  was  security  concerns,  but  he  also 
recognized  that  Hatfield's  system  threated  to  replace  him  as 
top  maanagment's  primary  source  of  financial  information. 
Hatfield  recognized  that  his  group's  system  was  a  threat  to 
the  corporate  staffs.  And  he  said  that,  even  if  the  technical 
problems  with  Lynx  had  all  been  solved,  the  staff  groups 
would  never  have  allowed  his  group  to  gain  significant  power. 
The  ESS  was  too  threatening  to  them.  But  this  potential  power 
struggle  never  surfaced  because  of  the  technical  failures  of 
the  system. 

Data  security  was  a  particularly  sensitive  issue  at 
SCC  because  of  problems  the  company  had  experienced 
previously.  It  is  sometimes  hard,  however,  to  separate  when 
security  concerns  are  the  real  reason  a  manager  resists 
providing  information,  and  when  they  are  just  a  smokescreen 
for  political  resistance,  most  specif icially  in  response  to 
the  fear  of  losing  power.  Security  is  a  much  talked  about 
issue  during  the  implementation  process,  and  is  often  used  as 
a  reason  for  not  providing  executive  access  to  certain 
information  through  ESS.  In  practice,  however,  when 
executives  at  SCC  were  given  the  option  of  protecting  their 
data  by  requiring  passwords  for  access,  they  rarely  used 
these  optional  security  measures.  "Security  turned  out  to  be 
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mostly  an  emotional  issue,"  said  one  product  center  manager. 
Finally,  one  of  the  best  examples  of  resistance  came 
from  the' technology  planning  vp  who  outwardly  rejected  the 
PC-based  ESS  because  he  felt  it  had  been  imposed  on  him  by 
someone  else  (the  CFO) . 

8.  Manage  Spread  and  System  Evolution 

When  an  ESS  is  used  by  the  executive  sponsor,  often 
the  user's  subordinates  and  some  of  his  or  her  peers  will 
also  ask  to  be  put  on  the  system  immediately.  This  is 
particularly  true  when  the  system  contains  information  that 
reflects  on  the  subordinates'  performance.  An  effective 
system  is  also  likely  to  result  in  a  rapid  increase  in  demand 
for  new  capabilities,  as  executives  begin  to  understand  how 
the  technology  can  be  applied  in  their  work. 

Both  of  these  factors  —  spread  and  evolution  —  must 
be  managed  carefully.  One  important  step  is  to  identify 
explicitly  who  will  be  using  the  system  and  take  into  account 
their  technical  orientations,  work  styles,  and  job  functions. 

Brohammer's  decision  to  design  the  PC-based  ESS  is  a 
dramatic  example  of  how  a  system  can  be  implicitly  designed 
for  one  executive  when  it  is  really  intended  to  be  used  by  a 
range  of  top  managers.  The  response  of  the  technology 
planning  vp  to  the  PC  system  best  illustrates  this  problem. 
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Not  only  was  he  defensive  about  being  told  to  use  a  system 
designed  by  and  for  somebody  else,  but  the  PC  didn't  even 
begin  to  address  his  needs  for  communication  support  and  an 
R&D  project  monitoring  system. 

When  trying  to  identify  who  the  users  of  an  ESS 
actually  will  bef  an  important  consideration  is  whether 
installation  and  use  of  terminals  is  voluntary  or  mandatory. 
Some  chief  executives,  like  Weathers,  will  just  insist  that 
all  of  their  vice  presidents  have  terminals  on  their  desks. 
Given  the  inherent  technical,  data,  application,  and  support 
shortcomings  of  the  pioneering  ESS's  today,  this  is  an 
unworkable  managerial  demand,  except  in  the  most  bureaucratic 
of  organizations.  Executives  with  a  bias  against  computer 
support  quickly  find  multiple  reasons  to  doubt  the  system's 
effectiveness  and  will  soon  ignore  it.  Use  of  the  system  must 
be  voluntary. 

The  ESS  development  process  at  SCC  identified 
different  work  styles  and  technical  orientations  that  were 
never  acknowledged  in  the  system  design  itself.  For  example, 
both  the  technology  planning  vp  and  the  vp  of  the  office 
systems  division  spent  very  little  time  in  their  offices  and 
did  a  great  deal  of  administrative  work  at  home.  It  is 
unrealistic  to  expect  an  executive  who  is  rarely  in  his  or 
her  office  to  make  significant  use  of  an  ESS,  unless  he  or 
she  has  a  terminal  at  home.  In  the  SCC  case,  there  was  a 
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clear  correlation  between  amount  of  time  spent  in  the  office 
and  the  use  of  the  ESS.  All  those  executives  who  made 
significant  use  of  computers  at  the  office,  spent  more  than 
50  percent  of  their  time  there. 

Another  work  style  question  concerns  how  an  individual 
likes  to  absorb  information.  Some  executives  prefer  looking 
at  numbers,  while  others  much  prefer  graphic  presentations. 
Ironically,  SCC's  developers  were  convinced  by  their  external 
market  research  that  graphics  were  what  executives  wanted. 
But,  at  SCC,  many  top  managers  said  they  actually  considered 
graphics  unimportant,  and  they  preferred  getting  information 
in  numerical  formats. 

Technical  orientation  is  a  factor  that  also  should  be 
explicitly  identified.  Members  of  the  design  team  assumed 
Weathers  was  very  comfortable  with  a  terminal  and  was  willing 
to  work  with  complex  command  structures.  Brohammer,  on  the 
other  hand,  only  wanted  to  hit  one  or  two  keys  to  get  last 
months  sales  report.  Understanding  these  different  technical 
orientations  is  essential  when  managing  the  spread  of  an  ESS. 

CONCLUSION 
This  paper  has  been  an  attempt  to  outline  the  critical 
ESS  implementation  issues  identified  in  our  field  studies. 
Research  in  this  area  is  difficult  because  there  are  a  large 
number  of  potential  variables  and  only  a  small  number  of 
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success  stories  in  ESS  implementation.  But,  as  the  case  of 
SCC  indicates,  there  is  much  to  be  learned  from  some  of  the 
failures.  And,  we  believe,  it  is  useful  to  expose  our  current 
conclusions  about  ESS  implementation  to  encourage  further 
discussion. 
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